RocketMQ详解（一）原理概览

RocketMQ详解（二）安装使用详解

RocketMQ详解（三）启动运行原理

RocketMQ详解（四）核心设计原理

RocketMQ详解（五）总结提高

RocketMQ在MQ中的地位毋庸置疑，java开发者的首选、必会中间件。笔者在深度使用后，结合apache官网、github、源码(版本4.8.0)，总结出这个系列文章，供大家参考。本节稍显枯燥，但是有必要读。

自学飞机票：

1.rocketMQ官网

2.github RocketMQ   中文文档

3.参数配置文档

 RocketMQ是按照典型的生产-消费模型设计的。

官网架构图黑白色太单调，从网上下了张彩图：

 如上图，RocketMQ主要由 Producer生产者、Consumer消费者、Broker代理、NameServer名称服务器 四部分组成。

负责发布消息，支持集群部署。Producer通过负载均衡选择Broker集群队列进行消息投递。

负责消费消息，支持集群部署。支持以push推，pull拉两种模式对消息进行消费。群组消费支持：集群方式和广播方式（见2.3）。

消息中转角色，负责存储消息、转发消息。主要包含2个功能：

Name Server是Topic路由的注册中心，支持Broker的动态注册与发现。生产者或消费者能够通过名字服务查找各主题相应的Broker IP列表。多个Namesrv实例组成集群，无状态（每个实例数据一样）。

  表示一类消息的集合，每个主题包含若干条消息，是RocketMQ进行消息订阅的基本单位。

 为消息设置的标志，用于同一topic下区分不同类型的消息。可以根据topic+Tag实现消息的精细化生产和消费。

消息系统所传输信息的物理载体，生产和消费数据的最小单位，每条消息必须属于一个主题。每个消息拥有唯一的Message ID，且可以携带具有业务标识的Key。系统提供了通过Message ID和Key查询消息的功能。

  Consumer消费的一种类型，应用通常主动调用Consumer的拉消息方法从Broker服务器拉消息、主动权由应用控制。一旦获取了批量消息，应用就会启动消费过程。

 Consumer消费的一种类型，该模式下Broker收到数据后会主动推送给消费端，该消费模式一般实时性较高。

  同一类Producer的集合，这类Producer发送同一类消息且发送逻辑一致。如果发送的是事务消息且原始生产者在发送之后崩溃，则Broker服务器会联系同一生产者组的其他生产者实例以提交或回溯消费。

  同一类Consumer的集合，这类Consumer通常消费同一类消息且消费逻辑一致。要注意的是，消费者组的消费者实例必须订阅完全相同的Topic。RocketMQ 支持两种消息模式：集群消费（Clustering）和广播消费（Broadcasting）。

集群消费模式下,一个消息只能被一个Consumer消费。

广播消费模式下，相同Consumer Group的每个Consumer都接收全量的消息。

普通顺序消费模式下，消费者通过同一个消费队列收到的消息是有顺序的，不同消息队列收到的消息则可能是无顺序的。（message queue见2.4 消息存储模型）

严格顺序消息模式下，消费者收到的所有消息均是有顺序的。

作为一个架构师，除了了解原理外还必须清晰知道一款软件的的功能特性，以便后期技术选型。

Apache RocketMQ上描述了6个业务特性：

Github上描述了12个设计特性。总结的挺好：

消息的发布是指某个生产者向某个topic发送消息；消息的订阅是指某个消费者关注了某个topic中带有某些tag的消息，进而从该topic消费数据。

消息有序指的是一类消息消费时，能按照发送的顺序来消费。顺序消息分为全局顺序消息与分区顺序消息，全局顺序是指某个Topic下的所有消息都要保证顺序；部分顺序消息只要保证每一组消息被顺序消费即可。- 全局顺序对于指定的一个 Topic，所有消息按照严格的先入先出（FIFO）的顺序进行发布和消费。适用场景：性能要求不高，所有的消息严格按照 FIFO 原则进行消息发布和消费的场景- 分区顺序对于指定的一个 Topic，所有消息根据 sharding key 进行区块分区。 同一个分区内的消息按照严格的 FIFO 顺序进行发布和消费。 Sharding key 是顺序消息中用来区分不同分区的关键字段，和普通消息的 Key 是完全不同的概念。适用场景：性能要求高，以 sharding key 作为分区字段，在同一个区块中严格的按照 FIFO 原则进行消息发布和消费的场景。

RocketMQ的消费者可以根据Tag进行消息过滤，也支持自定义属性过滤。消息过滤目前是在Broker端实现的，优点是减少了对于Consumer无用消息的网络传输，缺点是增加了Broker的负担、而且实现相对复杂。

RocketMQ支持消息的高可靠，影响消息可靠性的几种情况：1) Broker非正常关闭2) Broker异常Crash3) OS Crash4) 机器掉电，但是能立即恢复供电情况5) 机器无法开机（可能是cpu、主板、内存等关键设备损坏）6) 磁盘设备损坏

1)、2)、3)、4) 四种情况都属于硬件资源可立即恢复情况，RocketMQ在这四种情况下能保证消息不丢，或者丢失少量数据（依赖刷盘方式是同步还是异步）。

5)、6)属于单点故障，且无法恢复，一旦发生，在此单点上的消息全部丢失。RocketMQ在这两种情况下，通过异步复制，可保证99%的消息不丢，但是仍然会有极少量的消息可能丢失。通过同步双写技术可以完全避免单点，同步双写势必会影响性能，适合对消息可靠性要求极高的场合，例如与Money相关的应用。注：RocketMQ从3.0版本开始支持同步双写。

至少一次(At least Once)指每个消息必须投递一次。Consumer先Pull消息到本地，消费完成后，才向服务器返回ack，如果没有消费一定不会ack消息，所以RocketMQ可以很好的支持此特性。

回溯消费是指Consumer已经消费成功的消息，由于业务上需求需要重新消费，要支持此功能，Broker在向Consumer投递成功消息后，消息仍然需要保留。并且重新消费一般是按照时间维度，例如由于Consumer系统故障，恢复后需要重新消费1小时前的数据，那么Broker要提供一种机制，可以按照时间维度来回退消费进度。RocketMQ支持按照时间回溯消费，时间维度精确到毫秒。

RocketMQ事务消息（Transactional Message）是指应用本地事务和发送消息操作可以被定义到全局事务中，要么同时成功，要么同时失败。RocketMQ的事务消息提供类似 X/Open XA 的分布事务功能，通过事务消息能达到分布式事务的最终一致。

定时消息（延迟队列）是指消息发送到broker后，不会立即被消费，等待特定时间投递给真正的topic。broker有配置项messageDelayLevel，默认值为“1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h”，18个level。可以配置自定义messageDelayLevel。注意，messageDelayLevel是broker的属性，不属于某个topic。发消息时，设置delayLevel等级即可：msg.setDelayLevel(level)。level有以下三种情况：

- level == 0，消息为非延迟消息- 1